Conversation
| @@ -1,21 +1,15 @@ | |||
| FROM docker.ocf.berkeley.edu/theocf/debian:buster | |||
| FROM debian:buster | |||
There was a problem hiding this comment.
Any reason for not using OCF Debian? AIUI the main benefit is that it's configured to use our mirrors. If you want to keep things lightweight, you could look into using Alpine instead.
There was a problem hiding this comment.
It also includes a bunch of OCF specific stuff, specifically a bunch of ldap configuration and kerberos configuration. If a service doesn't depend on it, I would prefer to not use the OCF docker image for determinism's sake. I'm indifferent to the actual OS used, but seeing as it's already configured on debian, I don't see a reason to move to alpine or something.
Regarding mirrors usage, this thing will be rebuilt once every blue moon, so I don't think it there's a pressing need to use OCF mirrors. If you think that's a good idea however, I can spend ~10 minutes putting something in sources.list.
There was a problem hiding this comment.
We get some things like the correct timezone used, backports enabled, etc. that I think would be useful to have too. It also makes getting security updates and getting changes into all services much easier for us.
Does having the ldap config and all that extra matter much?
jvperrin
left a comment
There was a problem hiding this comment.
How have you tested this so far?
| @@ -1,5 +1,3 @@ | |||
| servicePipeline( | |||
| upstreamProjects: ['dockers/master'], | |||
There was a problem hiding this comment.
This is here so we get security updates, so I think it'd be better if it was left in place
jvperrin
left a comment
There was a problem hiding this comment.
I really like what you've done here so far, it would remove the basic auth and make logging more standard (with loki and all that). I'd be happy to approve it but do still think using our standard docker images and upstream build would be better, even if there is some extra overhead with it. Thoughts?
No description provided.